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(57) Abrege : Proc£de* pour r6aliser une migration de connexions dans une architecture multi-ordinateurs (cluster), depuis un premier 
noeud, appete noeud primaire ou operationnel, comprenant un premier ordinateur dudit cluster sur lequel une application logicielle 
initiale est executee, vers au moins un noeud secondaire comprenant un autre ordinateur dudit cluster. Ce proceed met en ceuvre 
une adresse r£seau virtuelle qui est portee par le premier ordinateur et qui est transferee sur T autre ordinateur, cette adresse r£seau 
virtuelle 6tant prevue comme lien de dialogue entre le cluster et des ordinateurs clients connected au cluster et concerned par T appli- 
cation logicielle. Les connexions concerndes peuvent par exemple etre associ£es a une application logicielle destined a etre repliquee 
sur un autre ordinateur de facon a permettre un basculement de service de 1* application initiale vers sa replique. 
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«Procede de migration de connexions dans une architecture 
multi-ordinateurs, proced§ pour realiser une continuity de 
fonctionnement mettant en oeuvre ce proc6de de migration , et 
syst£me multi-ordinateurs ainsi equip§» 

La pr£sente invention concerne un proced6 pour realiser 
la migration de connexions dans une architecture multi- 
ordinateurs. Elle vise 6galement un proc£d£ pour realiser une 
continuity de fonctionnement d'une application logicielle 
dans une architecture multi-ordinateurs (cluster) , mettant en 
oeuvre ce proc6de de migration, ainsi qu'un systeme multi- 
ordinateurs implementant ce proc6d6 de continuity de 
fonctionnement . 

Le domaine de l f invention est celui des clusters 
d f ordinateurs formes de plusieurs ordinateurs collaborant 
entre eux. Ces clusters sont par exemple utilises pour 
executer des applications logicielles. Ainsi, a un instant 
donn£, une application est executee sur l'un des ordinateurs 
0 du cluster f appele noeud primaire ou operationnel (OP) , tandis 
que les autres ordinateurs du cluster sont appeles noeuds 
secondaires ou « stand-by » (SB) , dans un contexte 
d 1 architecture redondante . 

Or, l f exploitation de tels clusters montre que se posent 
25 des problemes de fiabilite qui peuvent etre dus a des 
defaillances du materiel ou du systeme d' exploitation, a des 
erreurs humaines, ou a la defaillance des applications elles- 
memes . 

Pour r£soudre ces problemes de fiabilite, il existe 
30 actuellement des m£canismes, dits de haute disponibilite, qui 
sont mis en oeuvre sur la plupart des clusters actuels et qui 
sont bases sur un redemarrage automatique & froid de 
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1' application sur un nceud de secours parmi l'un des noeuds 
secondaires du cluster. 

Or ces mecanismes bas6s sur un redemarrage automatique 
ne permettent pas d 1 assurer une continuity totale du service 
fourni par 1 ' application en cours d f execution au moment de la 
defaillance . 

Se pose en particulier le probleme complexe de la 
migration des connexions de reseau qui doit etre resolu au 
moment du basculement de service entre deux ordinateurs d'un 
cluster. 

Un premier object if de la presente invention est 
d f apporter une solution a ce probleme en proposant un procede 
pour realiser une migration de connexions dans une 
architecture multi-ordinateurs (cluster) , depuis un premier 
noeud, appele nceud primaire, comprenant un premier ordinateur 
dudit cluster sur lequel une application logicielle initiale 
est execut6e, vers au moins un noeud secondaire comprenant un 
autre ordinateur dudit cluster. 

Ce premier objectif est atteint avec un tel procede de 
migration mettant en oeuvre une adresse r6seau virtuelle qui 
est portee par le premier ordinateur et qui est transferee 
sur 1' autre ordinateur, ladite adresse reseau virtuelle etant 
prevue comme lien de dialogue entre le cluster et des 
ordinateurs clients connectes audit cluster et concerns par 
1 1 application logicielle . 

Dans un mode de realisation avantageux, Les messages en 
provenance d f un client sont captures avant la prise en compte 
par la couche reseau du cluster. En particulier, lorsque ce 
procede de migration est mis en oeuvre dans le contexte d f un 
protocole TCP/IP, la capture des messages est effectuee au 
niveau des tables « ip ». 

La migration de connexions peut etre aussi appliqu^e, au 
del£ de la tolerance aux pannes, a la mobilite des reseaux: 
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re-connexion d'un ordinateur portable ou autre appareil 
communiquant mobile d'un reseau physique a un autre, sans 
perte des connexions et contextes applicatifs, alors que les 
solutions existantes mettent en oeuvre un serveur 
interm6diaire non necessaire avec le procede de migrations 
selon 1' invention. 

Par rapport aux travaux de recherche anterieurs sur la 
migration des connexions, le proced6 decrit selon 1' invention 
presente les avantages suivants : 

il ne n^cessite pas de modification du protocole de 
transport TCP, malgre les limitations que presente 
celui-ci, 

- par voie de consequence, les machines distantes ne sont 
impact6es en aucune mani^re lors de la mise en oeuvre 
du procede, 

1 1 implementation de la migration de connexions ne 
necessite pas de modification du systeme 
d' exploitation, mais simplement le chargement d'un 
module noyau dynamique independant. 

Les protocoles de transport bases sur la couche « socket 
IP-UDP » sont aussi automat iquement pris en compte, quelles 
que soient leurs caracteristiques (exemple: protocoles de 
streaming audio ou video) . 

II est important de noter que le procede de migration de 
connexions selon 1' invention peut prendre en compte une 
plurality de nceuds secondaires ou « stand-by », procurant 
ainsi un effet multi-6chelle (« scalabilite ») . 

Le procede de migration selon 1' invention peut §tre 
avantageusement mais non limitativement mis en oeuvre pour la 
migration de connexions qui sont associ6s k une application 
logicielle destinde £ etre repliquee sur un autre ordinateur 
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de facon a permettre un basculement de service de 
1' application initiale vers sa replique. 

Le procede de migration de connexions selon 1' invention 
peut aussi etre mis en ceuvre de facon completement autonome, 
independamment de situations de basculement d'une machine a 
une autre ou de replication d' applications logicielles. 

On peut ainsi prevoir d' appliquer le procede de 
migration selon 1' invention pour une optimisation automatique 
de ressources informatiques par partage de charge par 
repartition dynamique de processus. Ce procede de migration 
peut aussi etre applique pour une maintenance non 
interruptive par relocation a la demande de processus au 
travers d'un reseau de ressources informatiques, ou pour une 
preservation de contexte applicatif dans des applications 
15 mobiles. 

Un autre but de la presente invention est de proposer un 
procede pour realiser une continuity de fonctionnement d'une 
application logicielle dans une architecture multi- 
ordinateurs (cluster), cette application etant executee a un 
instant donne sur l'un des ordinateurs du cluster, appele 
nceud principal, les autres ordinateurs dudit cluster etant 
appeles nceuds secondaires, ce procede mettant en ceuvre le 
procede de migration de connexions selon 1' invention. 

Cet autre objectif est atteint avec un procede 
25 comprenant les Stapes suivantes : 

- maintien au fil de 1 • eau d'au moins un clone de 
1 ' application sur au moins un des noeuds secondaires, 

- en cas de detection d'une def alliance ou d'un 
evenement affect ant ledit nceud principal, basculement de 
service vers l'un au moins desdits clones, et 

- migration de connexions r6seau. 

Ainsi, avec le procede de migration selon 1' invention, 
il est desormais possible, grace a la migration des 
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connexions reseau, de rendre les basculements de service vers 
des clones , transparents pour le monde exterieur communiquant 
avec 1' application* 

Par ailleurs, le mecanisme de migration de connexions 
mis en ceuvre dans le procede de migration selon 1' invention 
n'implique pas une modification du code source de 
1' application et est done non intrusif dans 1 1 application,, £ 
la difference des proc^des de migration de l f art anterieur. 

Les clones mis en ceuvre dans le proedde de continuity de 
f onctionnement selon 1' invention sont dits « chauds », e'est- 
&-dire qu'ils sont la r^plique exacte de 1 ' application et de 
tout son contexte operatoire. lis sont mis £ jour 
regulierement (periodiquement ou sur tenements 

caracteristiques) . Ces clones contiennent toutes les 
ressources et informations requises par 1 1 application pour 
fournir son service. 

Le procede de continuity de f onctionnement selon 
1' invention permet en outre de superviser l'etat de toutes 
les ressources necessaires au bon f onctionnement de 
1' application. Quand la degradation redhibitoire de I'une 
d'entre elles est dytectee, le procede de continuity de 
f onctionnement selon l f invention pr6voit une election d f un 
clone coitime nouveau primaire et lui ordonne de prendre la 
main. 

Cette election est appelee basculement et est 
transparente pour le reste du monde qui communique avec 
1' application : bien que le nceud primaire soit mis hors 
service, le service fourni par 1 1 application n'est pas 
interrompu car il est repris avec tout son contexte par le 
clone elu. 

On peut ainsi garantir que tout message transmis par le 
reste du monde a 1 1 application sera traite, soit par le 
primaire (pr6-basculement ) , soit par le clone (post- 
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basculement) . Pour ce faire, le procecte de continuity de 
f onctionnement selon 1' invention peut en outre comporter un 
enregistrement sur chaque clone (en plus du mecanisme de 
clonage periodique) , de tous les messages regus par le 
primaire depuis la derniere mis a jour des clones. Ces 
messages seront reinject 6s dans le clone elu nouveau primaire 
en cas de basculement. 

La replication holistique, pour etre complete , inclut la 
replication de ressources « noyau », comme par exemple l f ytat 
des piles protocolaires mis en oeuvre pour g^rer la 
connectivity de 1 1 application a prot6ger avec le monde 
ext6rieur (ses « clients ») . 

Un avantage important procure par le proc6d6 de 
migration selon 1' invention est de rendre transparent pour 
les clients de 1 ' application le basculement du service 
applicatif du primaire vers un secondaire. Techniquement, 
cela veut dire que les connexions etablies par les clients 
avec 1' application lors de son f onctionnement sur le 
primaire, doivent etre transmises (migrees) vers les clones 
et ne doivent pas etre rompues lors d'un basculement. Cette 
exigence est non triviale car pour les applications 
concernees par le procede de continuity de f onctionnement 
selon 1' invention, le monde ext<§rieur (les clients) 
communique avec 1 ' application essentiellement via des 
connexions TCP/IP, un protocole point a point « attache » aux 
machines physiques sur lesquels resident applications et 
clients. 

Le proc6de de continuity de f onctionnement selon 
1' invention resout ce probleme en implementant un mecanisme 
de replication de l'etat de la pile protocolaire ainsi que 
d'un systeme d' enregistrement / re-jeu qui permet, suite a un 
basculement, de ryinjecter les messages regus par le nceud 
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primaire avant le basculement mais pas encore pris en compte 
par le clone. 

L'etat de la pile, dans le noyau du systeme 
d 1 exploitation, est periodiquement introspecte (analyse et 
capture) sur la machine primaire, cet etat etant transfere 
avec le point de reprise (checkpoint) holistique et restaure 
sur les nceuds secondaires . 

En parall^le, tous les messages recus par le noeud maitre 
sont interceptes au plus bas niveau (avant d'etre livres a 
1 ' application sur le noeud primaire) et transferes pour etre 
enregistres sur les nceuds secondaires. Sur les nceuds 
secondaires, ces messages sont sauvegardes depuis le dernier 
point de reprise regu. 

En cas de basculement, le nceud secondaire elu prend la 
main en faisant tourner 1 ' application a partir de son dernier 
point de reprise (ce point de reprise est legerement dans le 
passe par rapport a 1 ' application lors du basculement, 
puisque recu periodiquement par les nceuds secondaires) . 

Pour ramener ce clone dans l'etat present, c'est a dire 
dans l'etat de 1 ' application au moment du basculement, les 
messages enregistres sont reinjectes. En les rejouant, le 
clone nouveau primaire atteint alors l'etat de 1 * application 
au moment du basculement. Ce re-jeu, dans certains cas, peut 
se faire de facon acceleree (compression du temps, 
Elimination des « blancs ») . Pendant ce re-jeu, les 
communications avec le monde exterieur sont fermees. Si de 
nouveaux messages sont recus des clients pendant le re-jeu, 
ils sont refuses, mais sans deconnexion. Ce refus sera gere 
par le protocole (controle de flux) et sera vu par les 
clients comme un ralentissement du reseau ou du service. 

II faut noter que le re-jeu necessite l'adjonction 
specif ique d'un canal d' injection de messages dans la file de 
reception du driver de 1' interface reseau independamment du 
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niveau physique, le systeme d' emission de trames ne 
permettant pas le rebouclage (entrees-sorties half duplex) 
sur les interfaces physiques. 

A 1' issue du re-jeu, le clone est dans l'etat exact de 
1' application avant le basculement et reprend la main en re- 
ouvrant les communications avec le monde exterieur. 

II est a noter que dans certaines configurations et 
selon le but recherche, il est possible de mettre en ceuvre la 
politique de basculement a chaud sur un clone, sans mettre en 
oeuvre le re-jeu. Les impacts d'un tel scenario de reprise 
sont : 

- la rupture des connexions en cours, done, pour les 
clients connectes sur des sessions actives, niveau de 
protection inferieur a celui propose par le re-jeu, 
15 ~ la reprise a chaud (contexte applicatif preserve) 

immediate (pas de temps de re-jeu pendant lequel les nouveaux 
messages sont temporises), done, re-etablissement plus rapide 
du service nominal avec acceptation plus rapide de nouveaux 
clients. 

20 L' implementation de l'une ou 1' autre des ces politiques 

de reprise est un parametre adaptable. 

II est a noter que pour la mise en oeuvre du procede de 
migration selon 1' invention, on peut avantageusement utiliser 
des techniques d'ingenierie logicielle non intrusive 

25 dynamique, qui ont fait l'objet d'une demande de brevet 
publiee le 2 aout 2002 sous le numero FR2820221. Ces 
techniques d'ingenierie logicielle permettent de manipuler 
des applications dans leur representation binaire 
(executable), de facon a rendre le procede de realisation de 

30 continuity de f onctionnement selon 1' invention transparent 
pour 1 1 application et done generique. 

Suivant un autre aspect de 1' invention, il est propose 
un systeme multi-ordinateurs prevu pour executer sur au moins 
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desdits ordinateurs au moins une application logicielle, 
implementant le procede pour realiser une continuity de 
f onctionnement selon 1' invention- 

D'autres avantages et caracteristiques de 1' invention 
apparaitront a I'examen de la description detaillee d'un mode 
de mise en oeuvre nullement limitatif, et des dessins annexes 
sur lesquels : 

- la figure 1 illustre sch6matiquement un exeraple de mise 

en oeuvre du procede de migration selon 1" invention au 
sein d'un procedy de continuity de f onctionnement ; 

- la figure 2 illustre schematiquement un mecanisme de 

point de reprise (checkpointing) mis en oeuvre dans un 
procede de continuity de f onctionnement selon 
1' invention ; et 

- la figure 3 illustre schematiquement des fonctions de 

supervision et de surveillance assurees sur les noeuds 
d'un systeme multi-ordinateurs (cluster) selon 
1' invention. 

On va maintenant decrire, en reference aux figures 
precitees le f onctionnement du mecanisme de migration des 
connexions reseau mis en oeuvre dans le procede de migration 
selon 1' invention. 

La migration des connexions s'appuie sur 1 1 utilisation 
d'une adresse reseau virtuelle dite adresse virtuelle du 
cluster. Cette adresse est portee par la machine qui detient 
1' application operationnelle. Elle est transferee vers une 
machine SB lors du basculement (switch) . Les clients doivent 
s'adresser k 1 1 application clusterisee en dialoguant sur 
cette adresse virtuelle. 

La capture des messages se fait avant la prise en compte 
par la couche reseau. Sur TCP/IP, cette capture est faite au 
niveau des "IP Tables" se qui assure la portability. 
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Les messages regus sur I'adresse IP virtuelle assignee 
au cluster sont emis vers le ou les machines SB sur un canal 
de type multicast (diffusion simultanee en direction de 
plusieurs destinataires) fiable qui • s 1 assure de la 
transmission des paquets. Lorsque le message est regu sur 
toutes les machines SB, celui ci est transmis a la couche 
reseau du noeud operationnel OP, Sinon le message est supprime 
(la couche transport du distant assurant la retransmission) . 

Ce mecanisme permet de garantir qu'un message peut etre 
rejoue sur une machine SB lorsqu'il est pris en compte sur le 
noeud operationnel OP, Le filtrage "IP Tables" permet de ne 
s'interesser qu'au message concernant I'adresse virtuelle du 
cluster. 

Lors d'une copie (dump) , une marque de copie (dump) est 
emise vers les machines SB afin de dater la copie dans le 
journal (log) . Ainsi on sait a partir de quel paquet il faut 
commencer le re-jeu lors d'un basculement (switch), 

Le module "IP tables" est un module noyau independant de 
la couche TCP/IP qui est charge dynamiquement . Aucune 
modification de la pile TCP/IP n'est requise ni sur le 
cluster ni sur les machines distantes. 

Les appels systemes generiques getsockopt et setsockopt 
sont etendus, via un pilote (driver), pour capturer/modif ier 
les param&tres socket suivants: 

- ports local & distant 

- num6ro de reference local & distant 

- num§ro du prochain paquet k emettre & attendu 

- horloge (« timer ») d 1 emission & de reception 

- taille de fenetre (« window size ») 
etc. 

La sauvegarde de l'6tat de la « socket » prend egalement 
en compte la liste des paquets en attente d 1 emission (send 
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queue) , ceux qui sont en transit (emis mais non acquittes) , 
et les paquets regus mais pas encore lus par 1 ' application 
(file de reception : « receive queue ») . 

La sauvegarde est faite dans le contexte du processus au 
moment du dump, apres 1" emission de la marque de log. Ce 
mecanisme assure que tous les paquets seront rejoues* Si un 
paquet est re<?u entre 1' emission de la marque de log et la 
capture de l'etat de la « socket », celui-ci est 
automatiquement ignore par la couche transport lors du 
basculement (switch) . Ce traitement est un fondement de la 
couche transport. 

L 1 extension des appels syst&me getsockopt et setsockopt 
est faite par un module noyau charge dynamiquement qui ne 
requiert aucune modification du code source du noyau. 

Le procede de migration de connexions selon 1' invention 
peut etre directement integre au sein d'un procede de 
continuity de f onctionnement pour un cluster de machines, en 
reference a la figure 1. Un tel systeme met en ceuvre une 
supervision et une detection de defaillance, un mecanisme de 
migration de process incluant un mecanisme de point de 
reprise (checkpoint) , un mecanisme de migration de connexions 
selon 1', invention, et un gestionnaire de ressources systeme. 
Ce procede de continuity de f onctionnement inclut aussi une 
fonction d' introspection de ressources, un mecanisme de 
replication du systeme de fichiers, un mecanisme d' edition et 
de mise £ jour d'un journal des evenements, et un mecanisme 
de re-jeu. 

On va maintenant decrire le mecanisme de commutation mis 
en ceuvre dans une migration des connexions reseau au sein du 
procede de migration selon 1' invention. 

Lorsqu f une machine SB devient un noeud operationnel OP, 
l'adresse IP virtuelle est cre6 sur le nouveau noeud 
operationnel OP mais les regies de filtrage interdisent toute 
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arrivee de message de l'extdrieur pendant la phase de jeu. 
Une fois le jeu termine, les regies de filtrage sont 
modifiees afin de dispatcher les messages sur les machines 
SB. 

Si des messages sont 6mis par le site distant, ils 
seront detruits & 1' arrivee dans la machine nouvellement OP, 
et seront retransmis par la couche distante sur « timeout » 
(hors temps) . Ce mecanisme est un des fondements de la couche 
transport. 

La recreation des « sockets » (couche de communication) 
se fait en 2 phases: 

- avant re- jeu vers un « loopback » (dispositif de 

stockage virtuel) , 

- aprds re- jeu en les reconnectant vers l'exterieur. 

Avant le re- jeu, les « sockets » sont connectes £ un 
« loopback » qui permet la reinject ion des paquets 
enregistres depuis la derniere restauration. 

Les param&tres de la « socket » sauvegardes lors de la 
precedente copie « dump » sont remis en place via I'appel 
etendu setsockopt. 

Les paquets enregistres depuis la derniere restauration 
sont 6mis vers la couche transport comme s'il avait et6 regus 
directement d'un equipement distant (clients), Les messages 
transmis par la couche transport sont automat iquement 
detruits afin de ne pas perturber le distant. 

A la fin du re- jeu, l f etat de la « socket » correspond a 
celui sur le noeud operationnel OP avant le basculement 
(switch) . II. est alors possible de reprendre le dialogue avec 
le distant. Cette reprise se fait en modifiant les parametres 
« sockets » concernant I'adresse du distant, et en modifiant 
les regies de filtrage pour autoriser 1' entree et la sortie 
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de message sur l'adresse virtuelle du cluster. Le dialogue 
reprend alors normalement . 

Le procede de migration de connexions selon 1' invention 
peut etre mis en ceuvre dans le cadre d'une interaction entre 
un serveur operationnel et un serveur miroir tel qu'illustre 
par la figure 2, dans lequel un mecanisme de point de reprise 
(checkpoint) est active, avec generation de copies 
periodiques incr6mentales . 

Pour la mise en oeuvre d'un proc6de de continuity de 
f onctionnement selon 1' invention , entre un nceud operationnel 
d'un cluster et un ou plusieurs nceuds secondaires de ce 
cluster , une base MIB (Management Information Base) est 
accedee par des pilotes d' introspection et de surveillance et 
par des commandes du cluster , en reference a la figure 3. 
Cette base MIB intervient dans la gestion du cluster sur le 
noeud operationnel et sur des noeuds de « back-up » pour les 
fonctions de restauration et de point de reprise, de decision 
de basculement et d' organisation de ce basculement. Un 
gestionnaire de supervision alimente par la base MIN assure 
des fonctions de controle et de MIB synth<§tique, en relation 
avec une interface utilisateur graphique GUI. 

Bien sur, 1' invention n'est pas limitee aux exemples qui 
viennent d'etre d6crits et de nombreux airu§nagements peuvent 
etre apportes a ces exemples sans sortir du cadre de 
l f invention. 
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RE VEN D I CAT I ON S 

1. Precede pour realiser une migration de connexions dans une 
architecture multi-ordinateurs (cluster) , depuis un premier 
nceud, appele nceud primaire, comprenant un premier ordinateur 
dudit cluster sur lequel une application logicielle initiale 
est executee, vers au moins un nceud secondaire comprenant un 
autre ordinateur dudit cluster, caracterise en ce qu f il met 
en oeuvre une adresse reseau virtuelle qui est portee par 
ledit premier ordinateur et qui est transferee sur ledit 
autre ordinateur, ladite adresse reseau virtuelle etant 
prevue comme lien de dialogue entre le cluster et des 
ordinateurs clients connectes audit cluster et concernes par 
1' application logicielle. 

2. Procede de migration selon la revendication 1, dans lequel 
les connexions sont associes a une application logicielle 
destinee a etre repliqude sur au moins un autre ordinateur de 
fagon £ permettre un basculement de service de 1 ' application 
initiale vers sa replique. 

3. Precede de migration selon l'une des revendications 1 ou 
2, caracterise en ce que les messages en provenance d f un 
client sont captures avant la prise en compte par la couche 
reseau du cluster. 

4. Procede de migration selon la revendication 3, mis en 
ceuvre dans le contexte d'un protocole TCP/IP, caracterise en 
ce que la capture des messages est effectuee au niveau des 
tables « IP »• 
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5. Procede de migration selon l'une des revendications 
precedentes, caracterise en ce que les messages regues sur 
l'adresse reseau virtuelle sont emis vers le ou les 
ordinateurs secondaires sur un canal de type multicast. 

6. Procede de migration selon les revendications 4 et 5, 
caracteris6 en ce qu'il comprend une capture et une 
modification des parametres « socket », via des appels 
syst£mes gen6riques etendus. 

7. Proced6 de migration selon la revendication 6, caracterise 
en ce que les parametres « socket » captures et modifies 
incluent au moins l'un des parametres suivants : 

- ports local et distant 

- numero de reference local et distant 

- numero du prochain paquet a emettre et attendu 

- horloge « timer » d 1 emission et de reception 

- taille de fenetre. 

8. Proc6d6 de migration selon la revendication 7, caracterise 
en ce qu'il comprend en outre une sauvegarde de la liste des 
paquets en attente d' Emission, des paquets qui sont en 
transit et des paquets regus mais non encore lus par 
1 1 application . 

9. Proc6de pour realiser une continuity de f onctionnement 
d'une application logicielle dans une architecture multi- 
ordinateurs (cluster), cette application etant executee a un 
instant donne sur l f un des ordinateurs du cluster , appel6 
noeud principal, les autres ordinateurs dudit cluster etant 
appeles noeuds secondaires, ce procede mettant en oeuvre le 
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proc6de de migration selon l'une quelconque des 
revendications precedentes, 

caracteris6 en ce qu'il comprend les etapes suivantes : 

- maintien au fil de l'eau d'au moins un clone de 
1' application sur au moins un des nceuds secondaires, 

- en cas de detection d'une defaillance ou d'un 
6venement affectant ledit nceud principal, basculement de 
service vers 1'un au moins desdits clones, et 

- migration de connexions reseau. 

10. Proc6d6 de continuity de f onctionnement selon la 
revendication 9, caracterise en ce qu'il comprend en outre 
une mise & jour des clones de 1 1 application. 

11. Precede de continuity de f onctionnement selon la 
revendication 10, caracterise en ce que la mise a jour des 
clones de 1 1 application est periodique. 

12. Precede de continuity de f onctionnement selon l'une des 
revendications 12 ou 11, caracterise en ce que la mise a jour 
des clones de 1' application est declench6e sur un ou 
plusi^urs evenements caracteristiques . 

13. Procede de continuity de f onctionnement selon l'une des 
revendications 9 a 12, caracterise en ce qu'il comprend en 
outre une supervision de l'ytat de ressources n^cessairement 
au f onctionnement de 1' application. 

14. Procede de continuity de f onctionnement selon l'une des 
revendications 9 & 13, caracterise en ce qu'il comprend en 
outre, a la suite d'une detection d'une defaillance ou d'un 
evenement affectant le noeud principal, une etape pour elire, 
parmi des clones installes sur des noeuds secondaires, un 
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clone pour etre substitue a 1 » application initiale, le noeud 
sur lequel ledit clone elu est install^ devenant le nouveau 
noeud principal. 

15. Proced<§ de continuity de f onctionnement selon l'une des 
revendications 9 a 14, caracteris<§ en ce qu'il comprend en 
outre un enregistrement sur chaque clone de messages regus 
par le noeud primaire, ces messages etant r6injectes dans le 
clone 61u nouveau primaire en cas de basculement. 

16. Systdme multi-ordinateurs prevu pour executer sur au 
moins desdits ordinateurs au moins une application 
logicielle, implementant le procede pour realiser une 
continuity de f onctionnement selon l'une quelconque des 
revendications 9 a 15. 

17. Application du procede de migration de connexions selon 
l'une quelconque des revendications 1 a 8, pour une 
optimisation automatique de ressources inf ormatiques par 
partage de. charge par repartition dynamique de processus. 

18. Application du procede de migration de connexions selon 
l'une quelconque des revendications 1 a 8, pour une 
maintenance non interruptive par relocation a la demande de 
processus au travers d'un reseau de ressources inf ormatiques . 

19. Application du procede de migration de connexions selon 
l'une quelconque des revendications 1 a 8, pour une 
preservation de contexte applicatif dans des applications 
mobiles . 
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